The present invention relates to a method and a system for extending file system metadata. More particularly, the present invention relates to a method and a system for providing name and content extensible, multi-instance metadata for multiple format-specific file systems.
A typical computer system comprises a central processing unit, memory, peripheral devices such as data input/output devices and storage media such as floppy disks or hard disks. The devices communicate with each other via a computer operating system.
Computer operating systems include several different operational modules. One such module is the file manager. Client data stored on a storage medium is organized as a file system having an associated format, and the file manager controls the access to the file systems. The file manager provides file system access to clients using various software via Application Programmer Interfaces (APIs) adapted to the software. For example, the file manager may include an Apple Computer, Inc. API to interface with Apple software or an MS-DOS INT 21 API to interface with DOS software.
The file system stores, organizes and describes client data. The client data is stored in files. The files are arranged in each file system in a particular format. Each file system maintains its organization and description information, referred to as metadata, in format specific structures. Examples of such formats are HFS, MS-DOS FAT, ProDos, High Sierra, ISO 9660, Unix, and so on. The term format encompasses both physical disk format and network server access protocols. To read and write data from and to the file system, the file manager must be able to recognize the format of the file system.
Computer systems have been developed to access storage media organized under different formats by altering the format of the storage media into a format that is recognizable by the file manager. While this enables the computers to access storage media of different formats, the media may be altered to such an extent that they are unrecognizable by a file manager adapted to the original format of the storage media. Thus, it is difficult to use storage media interchangeably between computers with file managers adapted to different formats.
Systems have been developed to allow computers to access storage media having different formats without altering the formats of the storage media. For example, U.S. Pat. No. 5,363,487 to Willman et al. discloses a system adapted for use in a Microsoft.TM. OS/2 operating system for automatically and dynamically mounting a file system which recognizes the media. In this system, one or more data storage devices and a plurality of file system drivers are provided, including a default file system. The file systems are organized in a linked sequence. Each file system driver is able to access file systems of a particular format. The computer system continuously monitors all peripheral devices to detect any change in media in the peripheral storage devices. Whenever a medium in a data storage device is changed, or the first time the computer system accesses a data storage device, the first file system driver identified in the list of file system drivers is loaded, and a volume identifier is specified by the loaded file system driver. The volume identifier read from the medium is then compared with the identifier associated with the file system driver, and the file system driver is mounted if the identifiers match. Otherwise, the next file system driver identified in the linked list of file system drivers is loaded. The process is then repeated until each file system driver in the linked list of file system drivers has been tested or until a match is found. The default file system is mounted if no match is found.
A problem with this system is that it lacks flexibility. In particular, the identifier must be in a common known location for all volume formats which can be used by the system. Instead, it is desirable to allow each file system driver to use its own method of identifying the volume to provide increased flexibility in the volume format.
Other file managers are known, such as the Microsoft.TM. WINDOWS.TM. NT operating system. In this system, messages are sent to a plurality of objects that are maintained by each file system driver, the objects corresponding to the subject of the requests. Thus, if modifications to the processing of particular kinds of requests are necessary, they must be made at each file system driver.
Another system that has been developed is described in commonly assigned U.S. Pat. No. 5,574,903, herein incorporated by reference. In this system, a set of common message structures is employed that can represent a request regarding information stored in a file system in a way that is both independent of the format of that file system and independent of the API module issuing the request. The message structures are used as a common language for communication between the components of the mechanism. A central dispatcher receives requests for access to various storage media via multiple APIs. The dispatcher forwards the requests to format agents adapted to access storage media using a particular file system format. The API module requests are associated with the format agents via a central dispatch store. The store contains at least one first identifier for identifying the format agents, second identifiers for identifying a plurality of objects to which the requests can be sent, and mapping information for mapping between the second and first identifiers. When the request processing is complete, the format agents reply to the dispatcher with any information that needs to be returned to the original client. The dispatcher responds to the interface module which translates the information into a form that is appropriate to the interface. The information is then returned to the client.
This system provides a file manager that is capable of managing multiple, format-specific file systems, independent of the request content. The system provides a format specific, name-space extensible, single-instance metadata model. That is, the names of the units of data characterized in the metadata are extensible with this system. The extensibility of the metadata in the name space is achieved by the format agents and not by altering the native metadata of the file systems. Thus, the system provides interchangeability of file systems, enabling the file systems to be returned to the original machines for which they were intended to be used.
While this system provides metadata extensibility in the name space, the metadata content is format specific or invented by the format agent. Therefore, a request must be specific to a file system with a particular associated format or must be limited to that which can be commonly satisfied by all the format agents. Furthermore, this system provides only single instances of metadata. That is, only one instance of each unit of metadata is provided. This limits the flexibility of the system.
Multi-instance metadata is common in real world applications. Documents may have many authors, a number of events may happen on the same date, and so on. While there are systems that provide for multiple instances of metadata, these systems do not provide for associating the instances with particular clients. The conventional way to deal with multi-instance metadata is to choose a name for the characteristic, for example "author" or "date". Each value of the characteristic is then tagged with the name and an additional field, the instance, that discriminates one value from another. In this manner, instancing allows there to be many authors for a document and many events on the same date. However, a problem arises vis-a-vis name-space management in concurrent systems concerning how a client can choose an instance value and use it without another client first using the instance value. Further, if clients were allowed to create their own instances of attributes, a means to specify all instances of an attribute without knowing a priori each instance value would be required.
Thus, there is a need for a system that extends file system metadata content as well as metadata in the name-space to enable clients to fulfill requests from a number of different file systems without being limited as to which file systems the requests are directed. It is also desirable to enable clients' requests to be fulfilled without requiring that the requests be limited to that which may be commonly satisfied by all the file systems. Finally, there is a need for a system that allows clients to characterize multiple instances of file system metadata using client and/or file manager selected instance discriminants along with a method for associating format independent file system metadata with format dependent file system metadata.